home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / cisco-ios12.txt < prev    next >
Encoding:
Internet Message Format  |  1999-03-24  |  6.1 KB
  1. Date: Tue, 22 Dec 1998 14:41:44 -0800
  2. From: Jason Ackley <jason@ACKLEY.NET>
  3. Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
  4. To: BUGTRAQ@netspace.org
  5. Subject: Re: Cisco IOS 12.0 security bug and workaround
  6.  
  7. On Tue, 22 Dec 1998, John Bashinski wrote:
  8.  
  9. > characterizing it, and can't yet be completely sure which versions
  10. > or which platforms are affected.
  11.  
  12. Crashes:
  13. IOS (tm) 4000 Software (C4000-IK2S-M), Version 12.0(2)T
  14. (this is an old 68030 based 4000)
  15.  
  16. IOS (tm) 2500 Software (C2500-IOS56I-L), Version 12.0(2)
  17. (this is a 2514)
  18.  
  19. > This bug may cause different router platforms to crash differently.
  20. > Some routers have been observed to reboot and claim that they
  21. > were "restarted by power-on"; you won't necessarily get a stack
  22. > trace from one of these crashes.
  23.  
  24.  C4000 crashed with :
  25. System restarted by address error at PC 0x10006E8, address 0x802320
  26.  
  27. C2500 crashes with:
  28. System restarted by error - Illegal Instruction, PC 0x0
  29.  
  30. The 2514 seemed to take a bit longer to crash than the 4000, which was
  31. almost instant death.. Maybe it was just me..
  32.  
  33. I also noticed that the 4000 at least still is listening on the bootp
  34. server port, even tho I have 'no ip bootp server' set.. bug or feature?
  35.  
  36. Cheers,
  37.  
  38. --
  39. Jason Ackley     jason@ackley.net
  40.  
  41. -----------------------------------------------------------------------
  42.  
  43. Date: Tue, 22 Dec 1998 13:39:30 -0800
  44. From: John Bashinski <jbash@CISCO.COM>
  45. Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
  46. To: BUGTRAQ@netspace.org
  47. Subject: Update on Cisco IOS 12.0 security bug
  48.  
  49. -----BEGIN PGP SIGNED MESSAGE-----
  50.  
  51. This is an update for a message I sent about 5 hours ago.
  52.  
  53. Changes from the earlier message:
  54.  
  55.   1. We've found more affected versions. In addition to all 12.0 variants,
  56.      11.3AA and 11.3DB are affected. Plain old 11.3 is *not* affected.
  57.      Neither is, 11.3T, or any of the other 11.3 variants we've
  58.      looked at. We now know where the bug was introduced, and it's
  59.      unlikely that that code has made its way into any releases other
  60.      than 11.3AA, 11.3DB, and the 12.0 variants. When our Sydney office
  61.      wakes up, we'll be able to make some final checks.
  62.  
  63.   2. I left out the bug ID in the last message. It's CSCdk77426.
  64.  
  65.   3. The workaround text mentions broadcast addresses.
  66.  
  67. We still don't have fix dates; it can take some time to get fixes
  68. through the release process. When we have fix dates, we'll do
  69. a formal notice.
  70.  
  71. Amended message follows--
  72.  
  73. We've had a report of nmap UDP scans crashing Cisco routers running
  74. Cisco IOS software version 12.0. This was mentioned on BUGTRAQ, which
  75. has a very wide distribution. It would be very easy to exploit.
  76. Administrators should be on the lookout for potential exploitation of
  77. this bug.
  78.  
  79. We've verified that the problem does exist. We believe that it affects
  80. all Cisco routers running any variant of 12.0 (including 12.0T, 12.0S,
  81. etc.). 11.3AA and 11.3DB are also affected. Mainline 11.3 and 11.3T are
  82. not affected. None of the other 11.3 variants that we've checked are
  83. affected. Because of where the problem was introduced, we think that
  84. 11.3AA and 11.3DB are almost certainly the only affected 11.3
  85. variants. We will continue to check other 11.3 variants, and will issue
  86. another update if any turn up affected.
  87.  
  88. The problem appears to be caused by packets sent to the router's syslog
  89. port (UDP port 514). A tested workaround is to use an access list to
  90. block incoming syslog traffic. You'd do this with something like this:
  91.  
  92.     ! Deny all multicasts to port 514
  93.     access-list 101 deny udp any 224.0.0.0 31.255.255.255 eq 514
  94.     ! Deny old-style broadcasts
  95.     access-list 101 deny udp any host 0.0.0.0 eq 514
  96.     ! Deny network-specific broadcasts (*example*; depends on local netmasks)
  97.     access-list 101 deny udp any 192.31.7.255 eq 514
  98.     ! Deny router's own addresses
  99.     access-list 101 deny udp any host <router-addr-1> eq 514
  100.     access-list 101 deny udp any host <router-addr-2> eq 514
  101.     access-list 101 deny udp any host <router-addr-3> eq 514
  102.     ... etc ...
  103.     access-list 101 permit ip any any
  104.  
  105.     interface <interface-1>
  106.     ip access-group 101 in
  107.  
  108.     interface <interface-2>
  109.     ip access-group 101 in
  110.  
  111.     ... etc ...
  112.  
  113. The access list needs to block syslog traffic destined for any of the
  114. router's own IP addresses, or for any broadcast or multicast address on
  115. which the router may be listening. Don't forget to block all-zeroes
  116. broadcasts as well as all-ones broadcasts. It should be applied on
  117. all interfaces running IP, including virtual interfaces and
  118. subinterfaces (but not loopback interfaces).
  119.  
  120. This workaround *does* have a performance impact that may be significant
  121. for some users. The impact isn't usually extreme, but it may make a
  122. difference on a router that's already heavily loaded. Install it with
  123. care if you install it.
  124.  
  125. This bug may cause different router platforms to crash differently.
  126. Some routers have been observed to reboot and claim that they
  127. were "restarted by power-on"; you won't necessarily get a stack
  128. trace from one of these crashes.
  129.  
  130. Since this is still not completely characterized, and since we do not
  131. yet have any reports of exploitation, you may choose to hold the
  132. workaround in reserve and apply it only if you believe you are being
  133. attacked. We should have a formal notice with full details within the
  134. next few days. We cannot yet make any estimate of when a fix will be
  135. available; we should have more information by the time the formal notice
  136. comes out.
  137.  
  138. If you find that you are actually attacked with this, please report
  139. the attack to Cisco at "security-alert@cisco.com".
  140.  
  141. For more information on Cisco security procedures, see
  142.  
  143.    http://www.cisco.com/warp/customer/791/sec_incident_response.shtml
  144.  
  145.                                         -- J. Bashinski
  146.                                            Cisco Systems
  147.  
  148. -----BEGIN PGP SIGNATURE-----
  149. Version: 2.6.3in
  150. Charset: noconv
  151.  
  152. iQEVAwUBNoARckZi51ggEbh5AQEVlwf9EKP5iPzwfp4UpxsN1nnqLscyrLYYKXIs
  153. ce/EMcQP7znbkmse6cSFz5nOIKQpRl+c+rxLg8V3oeGTEriIyOA/jR0oVeU2Nn4N
  154. rS6daaorZU1ngGhZ4zTRYNoGbGOU4EjwnU/wJV1yrrIuLA3EAHz+67kT90qSRJy7
  155. R8ny+0tbtu7ZFdHI9Ccokal59HOz+Gbt29ep5/Ft0REVFoRqJCphJP06bT2HLIXZ
  156. qLXPBErmVc9fP0wqdf11tbc3zaiytBbVn6is9sFdqod14KeiBblOC99vfM7OG1KY
  157. rh3pLqSeLs76sw4RZycXAQWdLiY3Xgx3ZFwhB0YrpzUJnXGEDbcb7Q==
  158. =Xp1o
  159. -----END PGP SIGNATURE-----
  160.  
  161.